Software applications and solutions are increasingly delivered as a service from data centers and other remote computing environments that are colloquially referred to as the cloud. Deploying software in the cloud allows organizations to easily scale up or down to accommodate demand. Software solutions are sometimes delivered via public clouds hosted by a software vendor, but may also be delivered via private clouds or in some hybrid manner.
Upgrading such software solutions can be a challenging endeavor, especially when the scale of many deployments is considered. A great deal of down-time and lost productivity can occur when software deployments are shut down temporarily to accommodate an upgrade. In addition, customizations that a tenant may have made to its deployment of a given software solution can be lost or rendered ineffective by an upgrade.
Many software providers that operate at scale do not give their customers control over when a given software solution is upgraded. For example, some cloud-based email solutions are routinely upgraded from one version to the next automatically, without allowing customers to control how or when the upgrades are applied.
Various upgrade techniques have attempted to mitigate these challenges. In one example, when a service deployment is scheduled to be upgraded, a tenant can be notified ahead of time and can prepare a test accordingly. A test environment can be created to which the upgraded version of the software can be deployed. Tenant data may be ported into the test environment and access provided to a select group of personnel so that the new features and functionality of the software can be tested against various tenant scenarios and customizations. Once approval is given for the new software, the test environment is torn down and a completely new build is launched with the tenant's data incorporated into it.
In a brief example, a tenant deployment of a collaboration software service may be instantiated across a physical or virtual server farm. When an upgrade is available, the tenant may launch another server farm (typically virtual) to which the upgraded version of the collaboration service is deployed. Once the upgrade is tested and approved by the tenant, the server farm is torn down, anew server farm is created, and the collaboration service is deployed to the new server farm.